System and method for secure sticky routing of requests within a server farm

ABSTRACT

Upstream devices, such as load balancers or routers, within a server farm, may be configured to route requests to the servers handling sessions for those requests using a secure (e.g. encrypted) unique ID or network address received with requests identifying how requests may be routed through the server farm. Upstream devices or a server receiving a request that is not associated with a session may generate a unique ID or select a network address identifying how the request is routed through the server farm. The server handling the request forms a session ID and returns that session ID and the unique ID to the client that originated the request. Encryption may be performed on network addresses or session IDs. Upon receiving a request corresponding to an established session, an upstream device may then decrypt routing information from the encrypted unique ID or network address and send the request downstream accordingly.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to computer networks and in particular tohandling client requests in systems having multiple servers.

2. Description of Related Art

On computer networks, nodes may interact through requests for data,services, or other resources. Client nodes may generate requests andserver nodes may service those requests. Nodes may be stand-alonecomputers, servers, or other computing devices, as well as virtualmachines, threads, processes, or other network participants. To handle agreater volume of requests, a plurality of servers may be allocated toresponding to one or more types of requests and the servers as a groupmay be referred to as a server farm. For example, a bank, ticket office,or some other organization may use a server farm to process requestsfrom clients. The servers may be web servers on the Internet respondingto web clients.

To provide coherent service to clients, state or session information maybe collected and used by servers, so that their response to a givenclient may depend on session data for the client in the server farm. Forexample, session information may be used to implement a “shopping cart”used across multiple requests over one or more servers. It may be moreefficient to store the session information on a single server within theserver farm, rather than disperse that information, and ensure that thecorresponding server services the requests from the associated client.

A typical system may have a unique session ID assigned to correspond tocollected client session information. Initially, requests do not containsession IDs since there is not yet a session formed with the serverfarm. The first server to receive a request from a given clienttypically generates the session I). After a server creates a session fora client, the server generates a session ID to uniquely represent thatsession, and instructs the client to return the generated session ID insubsequent requests from that client. For example, a session ID may beencoded in the URLs the client is instructed to access or it may bestored in a server-generated cookie the client is instructed to sendback to the server with each request.

Requests may be routed between the clients and the servers through oneor more devices, which may be considered upstream from the servers anddownstream from the clients. These devices may be part of the serverfarm or may operate within the network or other system. For example, theserver farm may include one or more routers that receive the requestsfrom the network and route them to servers.

The work that a server performs processing requests it receives isreferred to as the load of that server. Depending on the allocation ofrequests and the processing required, the load may differ widely betweenservers and limit performance. Another example of upstream devices isload balancers. In order to distribute load across a plurality ofservers within a server farm, load balancers may be used. Load balancersmay be additional devices, may be part of other devices, or may includeother functionality. For example, load balancers may receive incomingrequests to the server farm and route the requests to individual serversin addition to determining where requests may be sent to better balanceloads in the server farm.

In some systems, a load balancer or other device may be configured toreceive incoming requests, examine them for a session ID, and then routethem to the server that generated the session ID so that sessioninformation is kept on a single server within the server farm. Thetechnique of using the session ID to select the server that will servicea given request is called “sticky sessions”, “sticky load balancing”, or“sticky routing” since the presence of a session ID causes the requestsassociated with that session to “stick” to a specific server.

Some systems may include load balancers or other devices in the serverfarm that receive requests and send them to servers. These devices maymaintain a mapping of session IDs to servers. These devices may thencompare the session IDs with the requests to their mapping informationto find the corresponding server. However, the size of the data for themapping may be prohibitive as there may be many session IDs-at least oneper client of the server farm.

In some systems, servers may provide their address, such as an Internethostname or address, to clients so that the client or devices within theserver farm, such as load balancers, may use that information to routesubsequent requests using standard Internet routing protocols to thecorresponding server. However, exposing the server addresses or otherdetails of the sever farm configuration communicates information aboutthe internal arrangement of the server farm to the client or othersoutside the server farm. As the client is typically a distrusted thirdparty, exposing information about the internal operation of the serverfarm may be a security risk.

Alternatively, an administrator may configure a load balancer andservers with a particular ID corresponding to each server as identifyinginformation. Servers may then include this identifying information intheir session ID without revealing information about the internalstructure of the server farm. However, the load balancer and server mustthen share data that allows the load balancer to target a specificserver from the identifying information. This implementation imposes aburden on server farm administrators, as configuration information forthese session IDs is then maintained for all load balancers and servers.

SUMMARY

A system and method is provided to enable upstream devices, such as aload balancer, router, or other device upstream from servers within aserver farm, to perform secure sticky routing of session requests. Inparticular, an upstream device may be configured to receive a requestwith a session ID and associated with a session. The upstream device maythen send the request to the server handling that session using securedata in the request identifying how requests may be sent downstreamthrough the server farm. The secure data may be an encrypted networkaddress or a unique ID stored as part of an encrypted session ID.Upstream devices may include a list of downstream devices, includingservers, to which they may send incoming requests. A unique ID ornetwork address may be dynamically generated or selected by upstreamdevices through which travels a request that is not already associatedwith a session on a server of the server farm, indicating how thereceived request may be sent downstream through the server farm.Upstream devices may automatically perform the unique ID generation ornetwork address selection in response to receiving requests. Theupstream devices may encrypt the network address or session ID with theunique ID.

A server handling a request without an associated session may form asession ID to identify a session for a client, including unique ID(s) ornetwork addresses received with the request from upstream device(s). Theserver may encrypt the session ID or network addresses before sendingthe session ID to the client that originated the request. The server mayencrypt network address or a session ID with a unique ID according to anencryption scheme that may be decrypted by an upstream device. In someembodiments, the server may provide the encrypted unique ID separatefrom the session ID. The client may then use the session ID withrequests within that session it sends to the server farm. Upon receivingrequests corresponding to established sessions, upstream devices may usea unique ID or network address with the request to send the requestdownstream. The network address or the session ID including the uniqueID an upstream device uses may be encrypted.

Upstream devices may determine the information that may be used touniquely identify the downstream server. This information may becommunicated to servers or any downstream device with each request. Theinformation may be included, embedded, or encoded within the request toreach servers. For example, an upstream device may use URL rewriting,cookies, headers, body, or new fields of the request, or other computingelement that may be used to store session IDs. Servers may use similartechniques to get session IDs and the unique ID(s) to clients. In oneembodiment, a server may determine the information to be used touniquely identify it. For example, the server receiving a client requestnot associated with an existing session may generate a unique ID orselect a network address identifying the server to include as part of asession ID. The server may secure the session ID or network address byencrypting it.

When sending a received request associated with a session, each upstreamdevice may extract information that identifies the device immediatelydownstream from it or the communication channel to use. The informationmay be secure and require decryption. For example, the received requestmay include a secure session ID with one or more unique IDs and theupstream device may decrypt the relevant unique ID to enable it todetermine where to send the request. The upstream device may then usethis information to send the request to the appropriate next device inthe server farm, enabling sticky routing for requests associated with agiven session across multiple tiers or nodes within a server farm. Inone embodiment, an upstream device obtains similar information bydecrypting a secure network address in the session ID. A server maystore distinct sets of session information associated with multipleclients. In one embodiment, the session information associated with agiven client may be stored on a plurality of servers.

In one embodiment, an upstream device may be configured to receive aclient request. If the client request is not associated with anestablished session, the upstream device may select one of a pluralityof servers and sends the client request to the selected server. Theserver may then generate a session ID and a unique ID in response to theclient request not associated with a session ID and send the session IDand unique ID to the client, wherein the unique ID comprises encrypteddata identifying the server. The unique ID may be include as part of orseparate from the session ID. If the client request is associated withan established session, the upstream device may identify one of theplurality of servers from encrypted data of the unique ID with theclient request and send the client request associated with anestablished session to the identified server.

In one embodiment, a computer accessible medium may include computerinstructions configured to implement an upstream device receiving aclient request. If the client request is not associated with anestablished session, the upstream device may select one of a pluralityof servers and send the client request to the selected server. Theserver may then generate a session ID and a unique ID in response to theclient request not associated with a session ID and send the session IDto the client, wherein the unique ID comprises encrypted dataidentifying the server. If the client request is associated with anestablished session, the upstream device may identify one of theplurality of servers from encrypted data of the unique ID with theclient request and send the client request associated with anestablished session to the identified server.

In one embodiment, a system may include an upstream device configured toreceive a client request. If the client request is not associated withan established session, the upstream device may be configured to selectone of a plurality of servers and to send the client request to theselected server. The server may be configured to then generate a sessionID and a unique ID in response to the client request not associated witha session ID and to send the session ID and unique ID to the client,wherein the unique ID comprises encrypted data identifying the server.If the client request is associated with an established session, theupstream device may be configured to identify one of the plurality ofservers from encrypted data of the unique ID with the client request andto send the client request associated with an established session to theidentified server.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates a computer system including a load balancer accordingto one embodiment;

FIG. 2 illustrates a method for a load balancer to handle requests forservers according to one embodiment;

FIGS. 3A and 3B illustrate a method for handling requests through aserver farm according to one embodiment, depending on whether they areassociated with an existing session;

FIG. 4 illustrates in more detail a method for handling a request notassociated with an existing session according to one embodiment;

FIG. 5 illustrates a computer system including a plurality of loadbalancers in a plurality of layers according to one embodiment; and

FIGS. 6A and 6B illustrate a method for handling requests through aserver farm with one or more layers for requests to travel beforereaching servers according to one embodiment, depending on whether theyare associated with an existing session.

FIGS. 7A, 7B, and 7C illustrate a method of handling requests through aserver farm using encryption according to one embodiment, depending onwhether they are associated with an existing session and the dataencrypted.

While the invention is described herein by way of example for severalembodiments and illustrative drawings, those skilled in the art willrecognize that the invention is not limited to the embodiments ordrawings described. It should be understood that the drawings anddetailed description are not intended to limit the invention to theparticular form disclosed but, on the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the present invention as defined by the appendedclaims. The various methods as illustrated in the Figures and describedherein represent exemplary embodiments of methods. The methods may beimplemented in software, hardware, or a combination thereof. The orderof method may be changed, and various elements may be added, reordered,combined, omitted, modified, etc. The headings used are fororganizational purposes only and are not meant to limit the scope of thedescription or the claims. As used throughout this application, the word“may” is used in a permissive sense (i.e., meaning having the potentialto), rather than the mandatory sense (i.e., meaning must). Similarly,the words “include,” “including,” and “includes” mean including, but notlimited to.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

A system and method is provided to enable upstream devices, such as aload balancer, router, or other device upstream from servers within aserver farm, to perform sticky routing of session requests., The systemand method may be implemented as part of a server farm for computersystem such as e-commerce sites, ticket offices, banks, or otherorganizations processing client requests in sessions, for example usingshopping carts, to provide secure interactions, or may otherwiseinteract across multiple requests with clients. Upstream devices fromservers in a server farm may be switches, routers, hubs, other servers,or any other computing device that may receive and send requests. Thesystem and method may be described with reference to a load balancer asthe upstream device as an example.

As illustrated in FIG. 1, in one embodiment a sever farm may includeservers 100 downstream from a load balancer 105. The load balancer 105may be any router, server, or other device configured to perform stickyload balancing while sending requests from clients downstream to servers100. The servers 100 may be any devices configured to handle requestsfrom clients and to store session information associated with one ormore clients in session stores 101. Clients 120 may be any deviceconfigured to generate requests and send them through the network 110 tothe server farm as well as receive data or other communications from theserver farm through the network 110. Network 110 may be a local areanetwork, a wide area network, a collection of different networks, theInternet, or another interconnected system of computing devices.

Servers 100B and 100C may store session information corresponding toclients 120 in session stores 101. Upon receiving a request from one ofthe clients, according to one embodiment the load balancer 105determines whether the request has an associated session. In particular,the load balancer 105 may examine the received request for an associatedsession ID or other data in the request indicating that it has anassociated session directly or indirectly. For example, a session IDidentifying a session may include data providing information for sendinga request downstream through the server farm to a server, indicatingthat a session associated with the request may be stored on that server.

If the load balancer 105 determines that a received request is notassociated with a session, the load balancer may select a downstreamserver and send the request downstream to that device with a uniquevalue identifying the downstream device. For example, load balancer 105may receive a request from client 120C, which has no associated sessionin the server farm as illustrated in FIG. 1. The load balancer 105 mayselect server 100A to process the request, for example according to itsconfiguration to provide load balancing. The load balancer 105 may thensend the request to server 100A with a unique ID identifying server 100Aas the recipient. The load balancer 105 may generate the unique ID orselect it from accessible data stores. For example, load balancer mayaccess a list of servers in the server farm or use handles referring toits available downstream connections to generate the unique ID.

The load balancer 105 may update or store information to indicate thatthe load of the servers, in particular the load on server 100A, may havechanged. In one embodiment, the load balancer 105 may inform one or moreother devices in the server farm of the load change, for example throughdistributed or shared memory storing loading information or by sending acommunication to the other devices.

If the load balancer 105 determines that a received request isassociated with a session, the load balancer may send the request to theserver 100 storing the corresponding session information in its sessionstore 101. For example, load balancer 105 may receive a request fromclient 120C with an associated session ID and one or more unique IDsindicating how the request may be sent downstream in the server farm.The session ID and unique ID may be part of the request, for exampleembedded or encoded within the request. Load balancer 105 may identifyserver 100A from a unique ID of the request and may send the request toserver 100A.

According to one embodiment, upon receiving a request from an upstreamdevice, a server 100 may determine whether the request has an associatedsession, which may be similar to that performed by the load balancer 105above. In particular, a server 100 may determine whether there is one ormore unique IDs associated with the request received that upstreamdevices may have added, indicating that this is a request without anassociated session. Alternatively, for example, the server 100 maysearch for a session ID or may instead, or also, try and match therequest with one of the session data 102 in its session store 101, forexample according to data associated with the request (such as “From” or“To” fields).

If the server 100 finds a corresponding session, the server may processthe request. Processing the request may involve operations internal tothe server 100 and/or communicating with one or more other devices,which may be outside the server farm. If the server 100 does not find acorresponding session, the server 100 may create a session and a sessionID. In one embodiment, creating a session may involve setting aside someresources, such as memory space, in the session store 101A. The server100 may then send the session ID the one or more unique IDs the server100 may have received with the request to the client that originated therequest. The one or more unique IDs may be encrypted or otherwisesecured form parties outside the server farm. The response may alsoinclude any data responsive to the request received by the server 100.

FIG. 2 illustrates a method for handling client requests in a systemhaving a plurality of servers, such as the system of FIG. 1. An upstreamdevice, such as a load balancer, may receive a client request, asindicated at 201. The upstream device may receive the request from aclient through a network such as the Internet. The upstream device maythen determine whether the received request is associated with anestablished session, as indicated at 202.

If the request is not associated with an established session, theupstream device may select a server to which to send the request and maydetermine a unique ID, such as an address or other data identifying theselected server, as indicated at 203. The upstream device may select theserver to which to send the request based on a desired serverdestination the upstream device wishes the request to reach, for exampleto attempt to balance server load in the server farm. The upstreamdevice may then send the request and the unique ID to the downstreamdevice, as indicated at 204. In one embodiment, the unique ID may beembedded in the request.

If the request is associated with an established session, the upstreamdevice may identify the downstream device to which the request may besent from the unique ID associated with the request, as indicated at205. In one embodiment, the unique ID is part of a session ID receivedwith the request. The unique ID may be identical to a unique ID sent bya upstream device to a server with a preceding request. The upstreamdevice may send the request to the downstream device identified, asindicated at 206.

FIGS. 3A illustrates a method for handling a client request that is notassociated with an existing session through a server farm according toone embodiment, for example as illustrated in FIG. 1. A load balancer asdescribed for FIG. 1 may receive a client request without an associatedestablished session, as indicated at 301, which may be from a clientacross a shared network or collection of networks. In one embodiment,the load balancer includes or has access to data indicating downstreamdevices to which it is connected and/or information on the load of thesedownstream devices. The load balancer is configured to select a serverand unique ID corresponding to the selected server, as indicated at 302.For example, the load balancer may access data it stores or has accessto, and determine to which downstream device it may send the request. Inone embodiment, the load balancer may take into account the memory orprocessor use, the number of requests assigned, and/or the number ofsessions handled by a server. The unique ID selected is configured toindicate information for selecting the server, so that received requeststhat include the unique ID may be sent to the same server in the serverfarm. For example, the unique ID may refer to a value given by the loadbalancer to the downstream device, may refer to some virtual networkconnection, or some other data that indicates to that upstream deviceone of its downstream devices. The load balancer may then send therequest with the unique ID to the selected server, as indicated at 303.

The server may receive the request and unique ID sent by the loadbalancer, as indicated at 304. The server may generate a session IDincluding the unique ID it received from the load balancer with therequest, as indicated at 305, so that the session ID not only identifiesa session but also provides information for upstream devices to identifythe particular server handling the session. For example, the server mayencode the unique ID within the session ID. Typically, the server mayinclude the unique ID information within the session in any way thatstill enable upstream devices to extract or decode that information fromsession IDs they receive with subsequent requests. The server may thensend a response that includes the session ID with the unique ID, asindicated at 306, to the client that originated the request. In someembodiments, the unique ID may be provided as a separate entity from thesession ID, such as within a separate cookie.

FIGS. 3B illustrates a method for handling a request that is associatedwith an existing session through a server farm according to oneembodiment, for example as illustrated in FIG. 1. A load balancer mayreceive a request with an associated established session, as indicatedat 351. The request may include a session ID with one or more uniqueIDs. Each unique ID may have been generated by one of the upstreamdevices of the server farm. The unique ID(s) may describe a path throughthe server farm down to the server configured to handle the request, forexample the server that stores the corresponding session data for theclient that generated the request. The load balancer may then identifyfrom a unique ID received with the request the server corresponding torequest, as indicated at 352. In one embodiment, an upstream device maydecode or extract the unique ID from the session ID, for exampleaccording to a configuration compatible with the encoding performed bythe server when generating the session ID. The load balancer may sendthe request to the identified server, as indicated 353. Upon receivingthe request, as indicated at 354, the server may respond to the request,as indicated at 355.

FIG. 4 illustrates in more detail selecting a downstream device to whichto send a request not associated with an established session anddetermining a unique ID, for example as indicated at 203 in FIG. 2. Alist of available downstream devices may be accessed, as indicated at401, to determine the routing options and select one of the availabledownstream devices to which to send the request, as indicated at 402.One of the routing options may be selected according to the load of theservers in the server farms to get the request processed by a serverwith a lesser load than other servers. A unique ID identifying the routeand/or the downstream device to receive the request may be determined,as indicated at 403.

The unique ID may then be encrypted to provide additional securityagainst undesired disclosure, as indicated at 404. In one embodiment, acryptographic hash function or other mechanism may be implemented toencode the information that uniquely identifies a given server withinthe session ID, such that the information still allows a load balancerto uniquely identify the server but cannot be retrieved by clients. Inone embodiment, the unique ID may be an Internet hostname or address andthe hash function or other mechanism may be tailored for encoding datain the format of Internet hostnames or addresses.

A load balancer may perform at least part of the handling of anon-associated request as illustrated by FIG. 4. In one embodiment, theencryption may be performed by the server downstream from the loadbalancer according to an encryption scheme that is compatible with theload balancer. For example, the server may receive unique IDs with therequest from upstream devices, may encrypt at least part of the uniqueIDs according to a scheme that may be decrypted by one or more of theupstream devices within the server farm, and may then include theencrypted unique ID as part of a session ID. In one embodiment, a servermay collate or otherwise compile received unique IDs and encrypt them asa whole.

The server farm may include one or more layers of devices for requeststo travel through before reaching servers. FIG. 5 illustrates a computersystem including a plurality of load balancers 505 and 506 as upstreamdevices in a plurality of layers according to one embodiment. In oneembodiment, different connectivity between a plurality of devices in aplurality of layers that enable routing of request received by theserver farm from client 120 through the network 110 to the servers 500may be implemented.

In one embodiment, each load balancer 505 and 506 may receive requestsfrom an upstream device and send them to a downstream device relative tothemselves. Where there is no associated established session with areceived request, the load balancer may also determine and transmit aunique ID providing information about the path taken by the requestthrough the server farm. For example, a request from client 120A maytravel through the network 110 to load balancer 505B. Load balancer 505Bmay then select load balancer 506C and send the request to load balancer506C with a unique ID. Load balancer 506C may receive the request andunique ID and may send them to server 500D, along with another unique IDit may generate. Each unique ID may indicate part of the path taken bythe request through the server farm and may enable load balancers 505Band 506C to perform communication along that path through the serverfarm.

In one embodiment, received requests may have an associated establishedsession and the load balancers may use the corresponding session ID toselect a downstream device and send the request to the selecteddownstream device. For example, a request with a session ID includingunique IDs may travel from client 120A through the network 110 to loadbalancer 505B. A load balancer may determine from the session ID withthe unique IDs the downstream device to which it should send the clientrequest and it may send the client request downstream according to thesession ID. In some embodiment, the unique IDs may be included withinthe request separate from the session ID.

For example, load balancer 505B may receive the request with a sessionID including the unique ID it generated above to indicate load balancer506C. Load balancer 505B may then send the client request to loadbalancer 506C with the session ID. In one embodiment, a load balancermay update, modify, or delete at least part of a session ID beforesending it downstream with a request. For example, load balancer 505Bmay delete the unique ID it used from the session ID, or it mayrearrange it so that it is at the end of the session ID, in accord withpossible expectations of the downstream device receiving the session. Inone embodiment, a load balancer may expect unique IDs in a particularpart of the session ID and/or it may expect the unique ID it is to useat the start of the session ID. In other embodiments, the unique IDs maybe separate from the session ID. Other devices upstream from servers mayperform similar functions. For example, load balancer 506C may receivethe request with the session ID from load balancer 505B. The session IDwith the unique ID(s) may indicate to load balancer 506C to send therequest to server 500D. Load balancer 506C may then send the request toserver 500D. Load balancer 506C may also update, amend, or delete partof the session ID. Servers 500 may be configured to identify thecorresponding session after changes to the session ID by upstreamdevices.

FIG. 6A illustrates a method of handling requests not associated with anestablished session traveling through a server farm with one or morelayers of upstream devices, such as load balancers, before reachingservers, for example as illustrated in FIG. 5, according to oneembodiment. After entering the server farm, a request may move throughone or more devices upstream from the server that may handle it.

An upstream device may receive a request that does not have anassociated established session, as indicated at 601. For example, therequest may not have a corresponding session ID. The upstream device maythen determine where to send the request, selecting a downstream deviceaccording to its configuration, as indicated at 602. In one embodiment,the load balancer may select one of the downstream devices according tothe load of the downstream servers. The load balancer may generate acorresponding unique ID, as indicated at 602, indicating the selecteddownstream device. In one embodiment, the upstream device receiving arequest with a unique ID may append the unique ID it generated with theunique ID received to obtain a combined unique ID. Alternatively,instead of appending unique IDs, upstream devices may merge, encode, orderive new unique IDs from a plurality of other unique IDs. Upstreamdevices may thus dynamically generate unique IDs for received requestsautomatically. The downstream device may then send the request and theunique ID(s) generated to the selected downstream device, as indicatedat 603.

If the downstream device is not a server, the receiving device mayoperate as another device upstream from the server and perform similarhandling of the request as indicated at 604. When a server receives therequest, it may also receive one or more unique ID(s), as indicated at605, depending on the number of upstream device through which therequest traveled and/or how each upstream device handled unique IDs. Theserver may then generate a session ID to identify session data for theclient that generated the request. The server may include in the sessionID the unique ID(s) it received, as indicated at 606. For example, theserver may include the unique ID(s) as part of the session ID, orotherwise include that information provided that the upstream devicesare configured to handle the session ID generated to recognize and/orextract the information they generated and sent to the server. In otherembodiments, the server may provide the unique ID(s) separate from thesession ID. The server may then send the session ID and the unique ID(s)to the client that originated the request, as indicated at 607.

FIG. 6B illustrates a method of handling requests associated with anestablished session traveling through a server farm with one or morelayers of upstream devices before reaching servers, for example asillustrate in FIG. 5, according to one embodiment. An upstream devicemay receive a request with an associated established session, asindicated at 651. The upstream device may identify a downstream devicecorresponding to the session associated with the received request, asindicated at 652, to which to route the request. The upstream device mayidentify the relevant downstream device using a unique ID associatedwith the request. For example, the upstream device may use a unique IDof the session ID received that indicates to which of the downstreamdevice to which it is connect the request may be sent. The upstreamdevice may then send the request to the identified downstream device, asindicated at 653. If the downstream device is not a server, thereceiving device may operate as another device upstream from the serverand perform similar handling of the request, as indicated at 654. When aserver receives the request, as indicated at 655, the server mayresponds to the request, as indicated at 656. The server may use orupdate session information to respond to the request.

There are various ways in which an upstream device in a server farm mayinclude unique ID(s) with requests it received. In one embodiment,client request URLs, some headers, the body, or other elements of theclient request may be manipulated. For example, a client request URL maybe rewritten to encode information describing the route the request istaking or its destination, thereby including the unique ID as part ofthe request framework or content. This information may be modified orappended to update its status and keep the information correct andrelevant as the request travels across the server farm.

In one embodiment, unique IDs transmitted with a request associated witha session may be manipulated while the request is in transit to reflectthe current position within the server farm of the request andfacilitate routing through multiple layers. For example, in oneembodiment load balancers in a server farm may be configured to use thefirst unique ID received with a request to determine to which downstreamdevice the load balancer may send the request. A load balancer may thendelete the unique ID it used, or rearrange it, before sending on therequest. In other embodiments, load balancers may expect unique IDs in aparticular part of the session ID and may be configured to ensure thatthe session ID has been updated to conform with the configuration ofsubsequent receivers.

FIGS. 7A, 7B, and 7C illustrate methods of performing secure stickyrouting. Encryption may be used to provide security by maintainingrouting data hidden from clients. Encryption may be any technique formaking the identifying information of one or more unique IDs not readilyascertainable to a third party, for example a client outside the serverfarm. In one embodiment, one or more encryption technique may be used.For example, encryption techniques such as a cryptographic hashfunction, Pretty Good Privacy (PGP), or RSA may be implemented.

FIG. 7A illustrates a method involving a request with no associatedestablished session, similar to FIG. 3A. As indicated at 701, a serverfarm may receive a client request without an associated session, forexample from a client that has not yet interacted with the server farm.A network address or other data identifying the location of a device inthe server farm may be selected in response to this client request. Asession ID for the request may be generated, as indicated at 702. In oneembodiment, an upstream device may receive the client request and sendit further downstream in the server farm to a server corresponding tothe network address. The server farm may be as illustrated in FIG. 1 anddescribed above for FIGS. 1-4. For example, the upstream device may be aload balancer, or another device receiving and sending client requestsin the server farm. The upstream device may be configured to select anetwork address indicating to which server to send client requests notassociated with an existing session.

The network address may be secured using encryption, as indicated at703. In one embodiment, the network address may be encrypted by theupstream device selecting the network address or at any time beforebeing sent to the client. For example, the server may encrypt thenetwork address before sending it as part of a session ID to the client.The device performing the encryption may be configured to use encryptionsuch that the encrypted session ID or network address may be decryptedby other devices in the server farm that receive the session ID withclient requests. For example, if the server encrypts the networkaddress, upstream devices that may process client requests including thesecure network address may be configured to be able to decrypt thesecure network address. The server may then send the session ID and thesecure network address to the client, as indicated at 704.

FIG. 7B illustrates another embodiment of a method involving a requestwith no associated established session, similar to FIG. 3A, byencrypting a session ID. As indicated at 711, a server farm may receivea client request without an associated session, for example from aclient that has not yet interacted with the server farm. A session IDmay be generated in response to this request that includes a unique ID,as indicated at 702. A server may generate the session ID using a uniqueID received from an upstream device with the client request. In oneembodiment, an upstream device may receive the client request and sendit downstream in the server farm to a server of the server farm. Theserver farm may be as illustrated in FIG. 1 and described above forFIGS. 1-4. For example, the upstream device may be a load balancer, oranother device receiving and sending client requests in the server farm.The upstream device may be configured to generate a unique ID to send toa server, as described above for FIG. 3. In one embodiment, a server maygenerate a unique ID. For example, a server may receive a client requestnot associated with an existing session and the server may generate aunique ID to include in a session ID that provides information to anupstream in the server farm for sending client requests with thatsession ID to the server. In other embodiments, the server may providethe secure (e.g. encrypted) unique ID separate from the session ID.

The unique ID may be secured by encryption, as indicated at 713, beforeit is sent to the client. In one embodiment, the device performing theencryption may be configured to use encryption such that the secureunique ID may be decrypted by other devices in the server farm thatreceive the unique ID with client requests. In one embodiment, theserver may perform the encryption after generating the session ID asdescribed above in reference to FIGS. 1-6. The server may send thesession ID and unique ID to the client, as indicated at 714.

FIG. 7C illustrates one embodiment of a method for handling a requestwith an associated established session involving a secure session ID ornetwork address, similar to FIG. 3B. In one embodiment, the encryptionmay have been performed as described above for FIGS. 7A or 7B. Asindicated at 751, an upstream device such as a load balancer may receivea client request with an associated session, for example from a clientthat has already interacted with the server farm. A session IDassociated with the request may include a unique ID or a networkaddress. The session ID or network address may be secured by encryption.The upstream device receiving the request may perform decryption on thesession ID to obtain a unique ID or the network address, as indicated at752, to identify a server to which to send the received request. In oneembodiment, a session ID may include multiple secure data components andthe upstream device may decrypt the data corresponding to informationindicating a server to which to send the request. In some embodiments,the secure unique ID may be provided separately from the session ID. Insome embodiments, only the unique ID is secured (e.g. encrypted). Theupstream device may send the request to the server identified by thenetwork address or unique ID obtained after decryption, as indicated at753. The identified server may receive the request, as indicated at 754.The server may use the associated session ID to determine the sessioncorresponding to the request. The server may then respond to the clientrequest, as indicated at 755.

In one embodiment, a server farm may include a plurality of upstreamdevices, as described above for FIGS. 5-6. In such an embodiment, afirst upstream device may decrypt a secure unique ID, session ID ornetwork address received with a request and may send the decrypted datadownstream with the request. Downstream devices receiving decrypted datamay be configured to use the decrypted data for routing the requestrather than performing their own decryption of secured data. In oneembodiment, an upstream device may decrypt other secured data receivedwith a client request for downstream devices in the server farm.

A client farm with upstream devices, such as load balancers, configuredto receive client requests including unique IDs that were dynamicallygenerated automatically for a previous request, may provide stickyrouting of session requests without administrator supervision. A clientfarm configured as described above may also enable routing of clientrequests through the server farm without upstream devices storingmapping information and/or exchanging mapping information. Theconfiguration of the server farm may enable the session ID to notdisclose implementation details of the server farm, such networkaddresses, to be exposed to clients.

Various embodiments may further include receiving, sending, or storinginstructions and/or data implemented in accordance with the foregoingdescription upon a computer accessible medium. Generally speaking, acomputer accessible medium may include storage media or memory mediasuch as magnetic or optical media, e.g., disk or CD-ROM, volatile ornon-volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM,etc.), ROM, etc. as well as transmission media or signals such aselectrical, electromagnetic, or digital signals, conveyed via acommunication medium such as network and/or a wireless link. A computeraccessible medium may be distributed, for example across memory of aplurality of computer systems, packets, or storage devices.

It will be appreciated by those of ordinary skill having the benefit ofthis disclosure that the illustrative embodiments described above arecapable of numerous variations without departing from the scope andspirit of the invention. Various modifications and changes may be madeas would be obvious to a person skilled in the art having the benefit ofthis disclosure. It is intended that the following claims be interpretedto embrace all such modifications and changes and, accordingly, thespecifications and drawings are to be regarded in an illustrative ratherthan a restrictive sense.

1. A method, comprising: an upstream device receiving a client request;the upstream device determining whether the client request is associatedwith an established session; the upstream device selecting one of aplurality of servers and sending the client request to the selectedserver if the client request is not associated with an establishedsession; the selected server generating a session ID and providing aunique ID in response to the client request, and sending the session IDand unique ID to the client if the client request is not associated withan established session, wherein the unique ID comprises encrypted dataidentifying the selected server; and the upstream device identifying oneof the plurality of servers from encrypted data of a unique ID providedwith the client request, and sending the client request to theidentified server if the client request is associated with anestablished session.
 2. The method as recited in claim 1, furthercomprising, the upstream device generating the unique ID and sending theunique ID with the client request to the selected server if the clientrequest is not associated with an established session.
 3. The method asrecited in claim 2, further comprising the upstream device encryptingthe unique ID.
 4. The method as recited in claim 2, further comprisingthe selected server encrypting the unique ID.
 5. The method as recitedin claim 2, further comprising the selected server encrypting thesession ID, wherein the unique ID is encrypted as part of the sessionID.
 6. The method as recited in claim 1, further comprising, theselected server generating the unique ID if the client request is notassociated with an established session.
 7. The method as recited inclaim 6, further comprising the selected server encrypting the sessionID, wherein the unique ID is encrypted as part of the session ID.
 8. Themethod as recited in claim 1, wherein the unique ID comprises a networkaddress of the selected server.
 9. The method as recited in claim 1,wherein said selecting comprises selecting to balance the load of eachserver in the plurality of servers.
 10. The method as recited in claim1, wherein said selected server generating and sending comprises a webserver responding to the client request, wherein the client request isfrom a web client over the Internet.
 11. The method as recited in claim10, further comprising the selected server establishing a session withthe web client and storing session state information for the session.12. The method as recited in claim 1, wherein the upstream device iscomprised within a hierarchy of upstream devices configured to routeclient requests to the servers.
 13. A computer-readable storage medium,comprising computer instructions configured to implement: an upstreamdevice receiving a client request from a client; the upstream devicedetermining whether or not the client request is associated with anestablished session; the upstream device selecting one of a plurality ofservers and sending the client request to the selected server if theclient request is not associated with an established session, whereinthe plurality of servers are coupled to the upstream device andconfigured to store session information; and the upstream deviceidentifying one of the plurality of servers from encrypted data of aunique ID provided with the client request, and sending the clientrequest associated with an established session to the identified serverif the client request is associated with an established session.
 14. Thecomputer-readable storage medium as recited in claim 13, wherein thecomputer instructions are further configured to implement the upstreamdevice generating a unique ID and sending the unique ID with the clientrequest to the selected server if the client request is not associatedwith an established session.
 15. The computer-readable storage medium asrecited in claim 14, wherein the computer instructions are furtherconfigured to implement the upstream device encrypting the unique ID.16. The computer-readable storage medium as recited in claim 13, whereinthe unique ID comprises a network address of the identified server. 17.The computer-readable storage medium as recited in claim 13, whereinsaid selecting comprises selecting to balance the load of each server inthe plurality of servers.
 18. The computer-readable storage medium asrecited in claim 13, wherein the upstream device is comprised within ahierarchy of upstream devices configured to route the client requests tothe servers.
 19. A system, comprising: an upstream device configured toreceive a client request; and a plurality of servers coupled to theupstream device and configured to store session information; theupstream device is configured to select one of the plurality of serversand to send the client request to the selected server if the clientrequest is not associated with an established session; the selectedserver is configured to generate a session ID and provide a unique ID inresponse to the client request and to send the session ID and unique IDto the client if the client request is not associated with anestablished session, wherein the unique ID comprises encrypted dataidentifying the selected server; the upstream device is configured toidentify one of the plurality of servers from encrypted data of a uniqueID provided with the client request and to send the client request tothe identified server if the client request is associated with anestablished session.
 20. The system as recited in claim 19, wherein theupstream device is configured to generate the unique ID and to send theunique ID with the client request to the selected server if the clientrequest is not associated with an established session.
 21. The system asrecited in claim 20, wherein the upstream device is configured toencrypt the unique ID.
 22. The system as recited in claim 20, whereinthe selected server is configured to encrypt the unique ID.
 23. Thesystem as recited in claim 20, further comprising the selected serverconfigured to encrypt the session ID, wherein the unique ID is encryptedas part of the session ID.
 24. The system as recited in claim 19,wherein the selected server is configured to generate the unique ID fora client request not associated with an established session.
 25. Thesystem as recited in claim 24, wherein the selected server is configuredto encrypt the session ID, wherein the unique ID is encrypted as part ofthe session ID.
 26. The system as recited in claim 19, wherein theunique ID comprises a network address of the selected server.
 27. Thesystem as recited in claim 19, wherein said selecting comprisesselecting to balance the load of each server in the plurality ofservers.
 28. The system as recited in claim 19, wherein said selectedserver configured to generate and to send comprises a web serverconfigured to respond to the client request, wherein the client requestis from a web client over the Internet
 29. The system as recited inclaim 28, wherein the selected server is configured to establish asession with the web client and storing session state information forthe session.
 30. The system as recited in claim 19, wherein the upstreamdevice is comprised within a hierarchy of upstream devices configured toroute the client requests to the servers.